@simov I guess this diverges from the test case which we have for timers-test in React, Riot & Oval:

1. represent 2000 div elements with a random value as text
2. every div element should render by itself on random 10ms framed intervals with its value changed (again at random)

Your PR (as I understand it) is:

1. represent 2000 div elements with a random value as text
2. every div element changes its own data value at random 10ms framed interval
3. the parent containing those 2000 div elements updates all of them at once on 10ms intervals

The bottom line is that I think the PR is an optimization of the implementation which to make a fair relative comparison with other implementations in React, Riot & Oval should be made there too.

So do you think that the above is sound and what do you propose to do further ❓

• A) implement the optimization to other tests as well

• B) drop it and mark Mithril's timers-test as N/A :)

  because as you pointed Mithril can't render single components and the test is about

  the ability of the framework/library to asynchronously update 2000 components

  So it sounds rather as test not suitable for Mithril's use cases (compared relatively of course to React, Riot & Oval)

For me the only problem is that Mithril doesn't batch rapid calls to m.redraw as promised. If that was working as advertised you won't even know what Mithril is doing under the hood.

The scenario is pretty much the same:
In React, Riot and Oval you have a method to specify which DOM branch you want to be updated, in Mithril you call global redraw and then Mithril decides what needs to be redrawn. So you have explicit vs implicit.

The only difference between these benchmarks is that the redraw is called outside of the timeout's callback, due to some weird bug in Mithril, the rest is implementation details - it's just how Mithril's redrawing cycle works compared to other frameworks.

To be fair we should have separate global redraw bench for every other framework in that list, because this scenario is much closer to something real. After that we can drop Mithril from this specific bench :)

@simov well the each-loop-test via its refresh is just that a 'global' (or top level) redraw. There we have a more precise numbers as well.

I know, that's the next thing on my list.

The point I'm making here is that when you have a swarm of incoming data you generally want to render the entire scene, not each and every element individually.

Closing in favor of #10